如果客户端缓存中没有查到对应的rowkey信息，需要首先到ZooKeeper上/hbase-root/meta-region-server节点查找HBase元数据表所在的RegionServer。向hbase:meta所在的RegionServer发送查询请求，在元数据表中查找rowkey所在的RegionServer以及Region信息。客户端接收到返回结果之后会将结果缓存到本地，以备下次使用。

如果发现currentNode后继节点的值小于等于待查询值，则沿着这条链表向后查询，否则，切换到当前节点的下一层链表。

NameNode本质上是一个独立的维护所有文件元数据的高可用KV数据库系统。为了保证每一次文件元数据都不丢失，NameNode采用写EditLog和FsImage的方式来保证元数据的高效持久化。每一次文件元数据的写入，都是先做一次EditLog的顺序写，然后再修改NameNode的内存状态。同时NameNode会有一个内部线程，周期性地把内存状态导出到本地磁盘持久化成FsImage（假设导出FsImage的时间点为t），那么对于小于时间点t的EditLog都认为是过期状态，是可以清理的，这个过程叫做推进checkpoint。

扩容操作一般分为两个步骤：首先，需要增加节点并让系统感知到节点加入；其次，需要将系统中已有节点负载迁移到新加入节点上。

对于本地数据，ShortCircuitLocalRead策略允许客户端绕过DataNode直接从磁盘上读取本地数据，因为不需要经过DataNode而减少了多次网络传输开销，因此数据读取的效率会更高。

Scanner的核心体系包括三层Scanner：RegionScanner，StoreScanner，MemStoreScanner和StoreFileScanner。

注意，这是一个非常关键的字段，表明了LSM树内存储的不只是数据，而是每一次操作记录。

合并原理是，先从这些待合并的数据文件中依次读出KeyValue，再由小到大排序后写入一个新的文件。之后，这个新生成的文件就会取代之前已合并的所有文件对外提供服务。

StochasticLoadBalancer是目前HBase默认的负载均衡策略

HBaseTTL过期的数据是通过Compaction机制进行删除的，因此会出现失效时间到期之后，数据还存在于系统之中但查询不出来的情况。

用于解决Google内部海量结构化数据的存储以及高效读写问题。

这种演变本质上是因为LRUBlockCache方案中JVM垃圾回收机制经常导致程序长时间暂停，而采用堆外内存对数据进行管理可以有效缓解系统长时间GC。

PageFilter并没有实现全局的分页功能，因为Filter没有全局的状态。

HBase中每个Region都是一个独立的存储引擎，因此客户端可以将每个子区间请求分别发送给对应的Region进行处理

Region迁移操作分两个阶段：unassign阶段和assign阶段。

稀疏的、分布式的、持久性的、多维的以及排序的

目前，HBase社区推荐使用的稳定版本为1.4.10

提升数据库读取性能的一个核心方法是，尽可能将热点数据存储到内存中，以避免昂贵的IO开销。

默认每次写入都需要执行一次RPC和磁盘持久化

更简单直接的方式是，将PrefixFilter直接展开，扫描[def,deg)区间的数据，这样效率是最高的